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SMTP Service Extension 
for 8bit-MIMEtransport 


Status of this Memo 


This RFC specifies an IAB standards track protocol for the Internet 
community, and requests discussion and suggestions for improvements. 
Please refer to the current edition of the "IAB Official Protocol 
Standards" for the standardization state and status of this protocol. 
Distribution of this memo is unlimited. 


1. Abstract 


This memo defines an extension to the SMTP service whereby an SMTP 
content body containing octets outside of the US ASCII octet range 
(hex 00-7F) may be relayed using SMTP. 


2. Introduction 


Although SMTP is widely and robustly deployed, various extensions 
have been requested by parts of the Internet community. In 
particular, a significant portion of the Internet community wishes to 
exchange messages in which the content body consists of a MIME 
message [3] containing arbitrary octet-aligned material. This memo 
uses the mechanism described in [5] to define an extension to the 
SMTP service whereby such contents may be exchanged. Note that this 
extension does NOT eliminate the possibility of an SMTP server 
limiting line length; servers are free to implement this extension 
but nevertheless set a line length limit no lower than 1000 octets. 


3. Framework for the 8bit MIME Transport Extension 


The 8bit MIME transport extension is laid out as follows: 
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(1) the name of the SMTP service extension defined here is 
8bit-MIMEtransport; 


(2) the EHLO keyword value associated with the extension is 
8BITMIME; 


(3) no parameter is used with the 8BITMIME EHLO keyword; 


(4) one optional parameter using the keyword BODY is added to 
the MAIL FROM command. The value associated with this 
parameter is a keyword indicating whether a 7bit message 
(in strict compliance with [1]) or a MIME message (in 
strict compliance with [3]) with arbitrary octet content 
is being sent. The syntax of the value is as follows, 
using the ABNF notation of [2]: 


body-value ::= "7BIT" / "8BITMIME" 


(5) no additional SMTP verbs are defined by this extension; 
and, 


(6) the next section specifies how support for the extension 
affects the behavior of a server and client SMTP. 


4. The 8bit-MIMEtransport service extension 


When a client SMTP wishes to submit (using the MAIL command) a 
content body consisting of a MIME message containing arbitrary 
octet-aligned material, it first issues the EHLO command to the 
server SMTP. If the server SMTP responds with code 250 to the EHLO 
command, and the response includes the EHLO keyword value 8BITMIME, 
then the server SMTP is indicating that it supports the extended MAIL 
command and will accept MIME messages containing arbitrary octet- 
aligned material. 


The extended MAIL command is issued by a client SMTP when it wishes 
to transmit a content body consisting of a MIME message containing 
arbitrary octet-aligned material. The syntax for this command is 
identical to the MAIL command in [1], except that a BODY parameter 
must appear after the address. 


The complete syntax of this extended command is defined in [5]. The 
esmtp-keyword is BODY and the syntax for esmtp-value is given by the 
syntax for body-value shown above. 


The value associated with the BODY parameter indicates whether the 


content body which will be passed using the DATA command consists of 
a MIME message containing some arbitrary octet-aligned material 
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("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT"). 


A server which supports the 8-bit MIME transport service extension 
shall preserve all bits in each octet passed using the DATA command. 


Naturally, the usual SMTP data-stuffing algorithm applies so that a 
content which contains the five-character sequence of 


<CR> <LF> <DOT> <CR> <LF> 
or a content that begins with the three-character sequence of 
<DOT> <CR> <LF> 


does not prematurely terminate the transfer of the content. Further, 
it should be noted that the CR-LF pair immediately preceeding the 
final dot is considered part of the content. Finally, although the 
content body contains arbitrary octet-aligned material, the length of 
each line (number of octets between two CR-LF pairs), is still 
subject to SMTP server line length restrictions (which may allow as 
few as 1000 octets on a single line). 


Once a server SMTP supporting the 8bit-MIMEtransport service 
extension accepts a content body containing octets with the high- 
order (8th) bit set, the server SMTP must deliver or relay the 
content in such a way as to preserve all bits in each octet. 


If a server SMTP does not support the 8-bit MIME transport extension 
(either by not responding with code 250 to the EHLO command, or by 
not including the EHLO keyword value 8BITMIME in its response), then 
the client SMTP must not, under any circumstances, attempt to 
transfer a content which contains characters outside the US ASCII 
octet range (hex 00-7F). 


A client SMTP has two options in this case: first, it may implement 
a gateway transformation to convert the message into valid 7bit MIME, 
or second, or may treat this as a permanent error and handle it in 
the usual manner for delivery failures. The specifics of the 
transformation from 8bit MIME to 7bit MIME are not described by this 
RFC; the conversion is nevertheless constrained in the following 
ways: 


(1) it must cause no loss of information; MIME transport 
encodings must be employed as needed to insure this is 
the case, and 


(2) the resulting message must be valid 7bit MIME. 
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5. Usage Example 


The following dialogue illustrates the use of the 8bit-MIMEtransport 
service extension: 


S: <wait for connection on TCP port 25> 
C: <open connection to server> 
S: 220 dbc.mtview.ca.us SMTP service ready 
C: EHLO ymir.claremont.edu 
S: 250-dbc.mtview.ca.us says hello 
S: 250 8BITMIME 
C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME 
S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok 
C: RCPT TO:<mrose@dbc.mtview.ca.us> 
S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok 
C: DATA 
S: 354 Send 8BITMIME message, ending in CRLF.CRLF. 
Ca 
S: 250 OK 
C: QUIT 
S: 250 Goodbye 
6. Security Considerations 


This RFC does not discuss security issues and is not believed to 
raise any security issues not already endemic in electronic mail and 
present in fully conforming implementations of [1]. 
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